[ preserving all Cc:-s, as requested by M-F-T header ]
On Mon, Mar 21, 2011 at 11:37:26AM +0000, Matt Zimmerman wrote:
> The DEX announcement seems to have been very well received. Thanks to
> everyone who forwarded, mentioned, re-dented and otherwise shared the news.
> We gained 10 new developers in the days following the launch!
Great!, thanks to everyone who has joined.
> = Ubuntu Ancient Patches Project =
>
> The vast majority of these have been reviewed and confirmed to have been
> merged or otherwise fixed in Debian. Thanks to David Paleino, Colin Watson,
> Nathan Handler and Steve Langasek for their contributions.
That's been a great initiative to start with as well. IMHO it's a
perfect example of how DEX initiatives should work: measurable goals not
too far reaching, relatively short time window, visible progress.
Matt, given you took care of coordination on this first initiative, I
wonder about the overhead of coordination. Was it low footprint for you
or not? IOW, how scalable you think DEX initiatives could be, in term of
needed organizational/monitoring efforts?
> This leaves the non-trivial ones which may require some discussion
> about what to do:
I'll postpone for a moment most of the comments on specific patches, as
I've seen they're progressing elsewhere on this thread. However, I've a
comment on this "patch commenting" process.
This list is great to reach out people who are interested in
cross-derivative collaboration. That, unfortunately, does not mean that
we can hope to have here all competences to comment on *specific
patches* that could apply archive wide. At best, we could identify the
teams to contact. I thus wonder whether it wouldn't be better to decide
that (maybe after a first round here?) patch feedback should be asked on
mailing lists where we have more hope to reach out to the "right"
people, such as -devel. What do other people think about this?
> I'd like to start compiling ideas for the next Ubuntu DEX project, once the
> above tasks have been completed. Here are some ideas:
>
> - Big merges: Create a list of packages with large or problematic deltas,
> and try to rationalize them. There are a relatively small number of
> packages which carry a lot of patches. We should try to get them in sync,
> and also try to solve the underlying problem which caused the divergence
> so that it doesn't happen again.
ACK on this. I expect to find within this a class of "branding" patches,
which derivative have used to enforce coherent themeing or the like,
where upstream software didn't offer a generic framework to do that
already. The goal for each such patches would probably be to implement
such a framework and have it accepted upstream (which might be
challenging).
On the converse side, we might also want to start maintaining a list of
divergences which are not meant to be reconciled. That happens sometimes
in Debian wrt upstream, it'll probably be the case also for derivatives.
Although those cases are unfortunate, it's in our interest to keep such
a list somewhere, so that we avoid re-considering them over and over
again.
> - Patch sweep: Generate a list of outstanding Ubuntu patches in the Debian
> BTS (we have usertags for this) and help to get them all merged: work with
> the maintainers, rework patches as needed, make NMUs where the package is
> orphaned etc.
ACK. Although I imagine the problem here is that there will be quite
some of them and that the set will be on continuous evolution. Wouldn't
it be better to identify well-defined subsets in that list, that can be
closed with more focused initiatives? Dunno ...
> - New packages: Continue the Utnubu effort to identify packages which are
> new in Ubuntu and not in Debian yet, and try to get them into Debian (file
> WNPP bugs? upload orphaned packages? find maintainers? sponsor the Ubuntu
> maintainer?)
Sponsor the Ubuntu maintainer to upload in Debian would probably be the
best option, possibly inviting them to maintain the package directly in
Debian. I suggest to ask for feedback on -mentors on this specific
topic.
> I would prefer to work on projects which can have a defined end point, which
> we can finish and move on, rather than open-ended projects like establishing
> new procedures, mentoring, and so on. Those are important too, but I think
> at this point there is a lot of concrete work we could do which will make a
> bigger difference in the short term, and help us learn more.
ACK!, showing concrete success at each DEX initiative it's important to
show progress in reconciling work which is done in derivatives. Along
the same line, we should think about clearly defining a success criteria
for each initiative and where to post "we did it" messages at the end of
each initiative.
Another one: assuming success wouldn't always correspond to 100% merges
of the initially defined set of patches, we probably need to define a
way to keep track of leftovers, for instance by collecting links to BTS
reports showing (usertagged) bugs associated to each DEX initiative. Do
we have something like that already? (Sorry, I'm writing this offline
and can't check the details for the ancient-patches case.)
Thanks for keeping the ball rolling,
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
Attachment:
signature.asc
Description: Digital signature