I learned something again tonight. Since there is an audit trail then your idea is perfect and first of all easy to handle.
Jan. On 14 November 2012 20:21, Rob Weir <robw...@apache.org> wrote: > On Wed, Nov 14, 2012 at 2:12 PM, jan iversen <jancasacon...@gmail.com> > wrote: > > On 14 November 2012 20:01, Rob Weir <robw...@apache.org> wrote: > > > >> On Wed, Nov 14, 2012 at 1:57 PM, jan iversen <jancasacon...@gmail.com> > >> wrote: > >> > +1 in general to your ideas, it would be VERY nice to have an easy > way, > >> and > >> > the more we all do to make it easy the more developers will work for > both > >> > projects. I do however have one question. > >> > > >> > Regarding the mark #AOOCONTRIBUTION. It an AOO committer take the code > >> and > >> > integrate it, would that not be a clear violation of the ICLA > paragraph > >> 7. > >> > As I read it, taking code requires a lot of extra red tape, compared > to > >> if > >> > someone actively sends the code and asks a committer to integrate it ? > >> > > >> > I might be wrong, but from past experience with apache, taking source > >> that > >> > has not clearly been sent with the purpose of integration, can lead to > >> > problems. Remember it is not easy to proof who actually set the flag, > >> > whereas a mail sent is a clear indication. > >> > > >> > >> I agree that this would only work if we know that the patch author set > >> the flag. But this can be done via normal means. If you recall, I > >> didn't ask for your fingerprints or a DNA sample before integrating > >> your patches ;-) Unless shown otherwise I hope we can assume that no > >> one is committing fraud, like editing someone else's commit to add a > >> tag to it. > >> > > No you did not, but as I wrote...I sent the patches on a public mail to > > you, so there are no doubt about my intentions. Just for the sake of > > discussion (I am not implying anybody would do the following), assume I > > issue a patch for AOO (or LO) and do not set the flag, LO (or AOO) wants > > the patch so an administrator "assumes" I forgot the set the flag and > helps > > me. > > > > So your point is that emails are harder to intentionally or > accidentally change. Version control and BZ are editable (even > Subversion memos can be changed) but we have these systems set up to > echo changes to email lists (issues@ and commits@) so there is a full > audit trail. So I think on the Apache side we can handle this. But > I'm not sure whether LibreOffice also echos all BZ changes, etc., to a > list. > > > If I may extend your idea a little, when the flag is sent, AOO/LO sends a > > confirmation e-mail to the developer and asks if it correct to integrate > > (correctly formulated this mail can even give the developer more > > motivation) ? > > > > Any solution that relies on custom development is a bit harder. > > > > >> > >> -Rob > >> > >> > Jan I > >> > > >> > > >> > > >> > On 14 November 2012 19:28, Rob Weir <robw...@apache.org> wrote: > >> > > >> >> I've heard some discussion and interest in this topic off-list. > There > >> >> has been some practical experience, but nothing that we've written > >> >> down or promoted. I'd be interested in seeing if we can come up with > >> >> some solid best practices. > >> >> > >> >> The problem: Many (most?) open source contributors are not opposed > to > >> >> AOO or LO. They are just interested in helping out. If they produce > >> >> a patch, or documentation, fix a bug or add a translation, they want > >> >> to maximize the public good that comes from that work. License > >> >> differences are confusing and frustrating and bring them no joy. > They > >> >> want a set of clear instructions for how they can do the most good > >> >> with the least process overhead. > >> >> > >> >> Naturally, I'm looking at this from the AOO side. But most of these > >> >> issues are symmetrical. So for sake of argument, suppose I identify > >> >> myself primarily as a LibreOffice developer/translator/technical > >> >> author, and I want to make my work available more broadly. What > >> >> should I do? As I see it, the issues are threefold: communications, > >> >> technical integration and license. > >> >> > >> >> On the communications side, how do I let AOO know that I've done work > >> >> that I want to contribute to them? Sending a note to dev@ or > posting > >> >> a patch in AOO's BZ would work, of course. But both require extra > >> >> work for the contributor. Are there any lighter weight ways of doing > >> >> this? For example, could we suggest a tag that could be used in git > >> >> or Bugzilla, for the contributor to indicate their intent that the > >> >> contribution be made available to AOO as well? Something like > >> >> #AOOCONTRIBUTION ? That would make it easy for us to search for such > >> >> items. > >> >> > >> >> Technical integration -- Due to divergence between the projects, not > >> >> every LO patch can be applied to AOO automatically. Some will, but > >> >> many will require adaptation. Certainly the contributor could > >> >> integrate and build their patch for both products. That would be > >> >> idea. But it is asking a lot. Would we accept less? Or maybe we > >> >> sugest areas where technical integration would be easier and require > >> >> no extra work? Otherwise, integration would require extra work on > our > >> >> end. But this is not fatal. In fact it could lead to a set of "easy > >> >> tasks" for new developers. > >> >> > >> >> License -- the differences here are well-known, but are easily > solved. > >> >> A contributor merely needs to state that they are making their patch > >> >> available to AOO under ALv2. There are various ways to record this > >> >> fact publicly. One is to make the statement in the source system > (git > >> >> or BZ). But that is extra work. Another way might be submit an iCLA > >> >> to Apache. Another way might be to publicly record an intention on > >> >> our dev@ list, along the lines of, "All of my (future/past) > >> >> LibreOffice contributions should be considered also contributions > >> >> under the Apache License 2.0 to the Apache OpenOffice project". > >> >> > >> >> Another other ideas? > >> >> > >> >> -Rob > >> >> > >> >
