Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal

[Yann Droneaud]

Thomas Lord <address@hidden> writes:

>     > From: Yann Droneaud <address@hidden>
>
>     > what's going to be fixed, to be merged, to be improved in for the
>     > candidate release ?
>
> See the recent annoucement.
>

It was posted while i wrote the message ;)

>     > It's very unclear on what's your working on
>
> I asked Matthew to identify the most critical fixes from the 1.2.2
> branch that could be merged quickly and to start with those.
>
> Matthew has announced (not where you've seen, apparently) that he's
> also dredging the 1.2.2 line to pull out other change and prepare them
> for the GNU mainline.
>

But there's no formal list or description of what will be fixed or merged.

>     > Since James stopped his work of integrator, I feel the development has
>     > stalled, 
>
> James sustained a very high merge rate while, to put mildly,
> neglecting to cooperate with the GNU release process.   Thus, his high
> merge rate is not so high after all when you consider that a few weeks
> of his work has to be gone over a second time by Jivera.
>
> It's slightly ridiculous to say much of anything at all about the
> current change rate of the mainline.  After the big crisis, we've had
> a new person in the integrator / release manager seat for just a
> couple of weeks now.  In that time he has produced a test candidate
> with the very highest priority changes.  So far, to me, in the context
> of recent history: I think the change rate is finally starting to look
> good again.  But really, we won't know for sure for another month or
> two, at which point we can look back and see how we've been doing.
>

But to my point of view, the "change rate" is not visible.

>
>     > Jivera seems to work on his own, there's little discussion on
>     > the mailing list, no report, no announcement of what's being commited,
>     > merged, etc ... it's hard to see what's will be done.
>
> There's not a lot to discuss, just now: it's pretty much deterministic
> that he has to pick a certain subset of the changes from 1.2.2 and
> that's likely to keep him mostly busy through the first two test
> candidate releases.   
>
> During that time, if someone has some change they want to make a
> priority, I suggest that they make their case on the -dev list.
>
> But you're right about one thing: there isn't enough transparency in
> the project right now.  Yours isn't the only feedback I've gotten
> asking for more and, in fact, making the project /systamatically/ more
> transparent is something I've been working on tools for very hard
> recently.
>

I'm not asking for "systamatically". I'm just asking for more
information,

>
>     > We switch from bazaar to cathedral model
>
> I'm not sure that that's even a meaningful statement.  

I tried to mean that James was merging patches as they come, without
following a development schedule of what features to add, merge,
improve: it's bazaar style.

As i read the rel-src-mgt.txt, we need some sort of roadmap for the new
features (bug fix are generally not candidate for that ;) :
this is catheadraal style.

> The only real
> change for submitters here is that we ask them to prepare submission
> branches rather than ad hoc merges.  Here is a reason why:
>
> 1. Ad hoc merges take a lot of time and effort to process by hand,
>    and even then, it is an error-prone process.   Submission 
>    branch merges, on the other hand, are very easy to quickly process
>    and get to a state where they can be reviewed.   Thus, part of the
>    change here is to help protect the scalability of the integration
>    manager: to ask contributors to take on the error-prone grunt work
>    by preparing a clean submission branch instead of just tossing an 
>    ad hoc merge request over the wall.
>
> 2. There are many ancillary benefits (for everyone, including good
>    forks) from having the mainline working with submission branches.
>    Such submission branches are, in effect, revisioned changesets and
>    so if modifications to a change are needed before it can be merged,
>    a submission branch provides a convenient mechanism for that.
>    Submission branches also provide a clean and regular mechanism for
>    cherry-picking from the queue of mainline contributions.
>
> The few people who are making noises about the horribleness of the
> patch log pruning that submission branches involve haven't, afaict, 
> thought the matter through:  yes, we need an "=merges" file to support
> cherry-picking of submission branches but, given that file, the 
> log pruning is harmless (doesn't harm smart merging) and beneficial
> (manages the log directory size sanely).
>
> It's a project /without/ a log pruning policy that you'd really want
> to watch out for.  Can you imagine, for example, an arch-based linux
> kernel project that simply retained /every/ patch log file from
> anywhere in the ancestry of the kernel?   For a long time I thought
> projects should just prune based on time ("that log is so old we
> probably don't need it anymore") but the pruning based on submission
> branches is much, much cleaner.
>

I'm not discussing the new "process" for merge. No need to justify.
I have the same concerns than other reluctant about log pruning,
but i'm waiting to see what will happen. I acknoledge the patch log must be
pruned to scale, but arch protocol doesn't have currently the support
for it. (So the pruning happen a little too early since it doesn"t have
the infrastructure now).

>
>
>     > The new model did not encourage contribution because I don't see how
>     > to submit them for review, when they will be merged, and if they will
>     > ever be merged (the need for copyright assigment: i have no real problem
>     > with it, but tell me how to complete it, and if it's legal to do it in
>     > my country: you nead to ease the process and give information if you
>     > want people to do it quickly)
>

So, no one have solution, information for me ?
Can i submit my "automatic changelog fix" without the copyright
assignment done ? 

I thnik it's just a trivial fix i think:
http://bugs.gnuarch.org/cgi-bin/mergereport.cgi?merge=57

Like this one, but i created a new file :
http://bugs.gnuarch.org/cgi-bin/mergereport.cgi?merge=56


>     > So what are the goals for the next days, weeks, months ?
>
> Hopefully I've answered for the next .5 - 1.5 months: namely continue
> to catch up with what seems valuable from 1.2.2, making that available 
> as testing candidates.
>
>     > What have to be done, what's need to be improved ?
>
> /That/ topic is something I'll be addressing over the rest of this
> week and the beginning of next, I hope.   I've been madly hacking 
> to set up an infrastructure for nicely maintaining such "managerial
> state" of the project.
>

Nice to read.
(I'm quite late in reading gnu-arch messages).

>
>     > (PS: don't pay attention to my english, correct if you can,
>     >  ask me if you really don't understand ;)
>
> (It seems fine.  I didn't notice that you weren't a native speaker
> until I read your PS.)
>

And for the new message ? ;)

Regards

-- 
Yann Droneaud      <address@hidden>        +33 6 88 40 82 43
<address@hidden>  <address@hidden>  <address@hidden>
http://droneaud.com/ http://meuh.org/ http://meuh.tuxfamily.org/
1024D/BEA43321 5D91 B5B0 5137 B8FE 6882 FE19 CAA0 6F05 BEA4 3321