Re: DEX update and next steps
On Wed, Mar 23, 2011 at 10:44:11AM +0800, Stefano Zacchiroli wrote:
> On Mon, Mar 21, 2011 at 11:37:26AM +0000, Matt Zimmerman wrote:
> > = Ubuntu Ancient Patches Project =
> [...]
> 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?
It's a bit hard to tell, because I was also doing a lot of patch review
myself. The main coordination work so far has been (not all done by me):
1. Announcing the project (here, Planet, helping debian-publicity)
[one-time work]
2. Setting up the infrastructure for DEX in general (ikiwiki, git, writing
web pages)
[one-time work]
3. Setting up the infrastructure for ancient-patches (web pages, status.txt,
update.py)
[should become less over time as we develop tools which are reusable
across projects]
4. Adding new people to the Alioth project and welcoming them
[there was a spike due to the initial announcement, but this should not
be much work going forward]
5. Writing this progress update and other mailing list communications
[this needs to continue regularly for each project we do]
At the end of the project, I expect to write a summary conclusion to share
on Planet (and maybe elsewhere?): how many patches were reviewed, what
happened to the outstanding ones, etc.
> 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
I think we did more or less as you described this time, but maybe I've
overlooked something.
Since one of the goals for DEX is to build expertise within the team on "the
right way" to handle these patches, I think it's important to discuss this
with other members of the team. I also wanted to get a "second opinion"
from a teammate before approaching the maintainer, because we are
inexperienced with this process and still learning how it should work.
The feedback I got on this list was very useful to me in continuing to
process the patches (one of them I was able to drop entirely based on
discussion, and not bother a maintainer at all).
Once we had a team discussion about the patches, then I tried to contact the
"right" people in each case. The advice from the group was useful here as
well (e.g. email Martin Schulze directly). Here also, I involved other team
members by CCing -derivatives, so that others could see what was going on,
participate in the discussion if they had something to add, and pick up the
conversation if I can't for some reason.
So basically we reviewed in three stages:
1. Individual contributors reviewed patches in git and took decisions about
them where they were confident
2. As coordinator, I took the remaining issues to the group via
-derivatives, made suggestions and asked for feedback
3. As an individual contributor, I followed up on some of the patches by
contacting the appropriate person or team in Debian, CCing -derivatives
> , such as -devel. What do other people think about this?
Where we want to have discussion about what to do with a patch, I think we
can have that within the team.
When we want to reach the specific people who can help, I think it's best to
go directly to them (where we know who that is).
If we can't agree, need help, or don't know where to go, we can to go to
-devel.
If we can't get resolution on -devel, we can ask for more official help
(e.g. the technical committee?).
I'm a bit concerned about bikeshedding if we involve too many people early
in the discussion who may have only opinions, and no role to play in solving
the problem.
> > - 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).
Indeed.
> 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.
Yes. This seems like something which should be handled by
http://dep.debian.net/deps/dep3/ (Forwarded: not-needed)?
> > - 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 ...
Yes, that's what I had in mind. Allison suggested, for example, taking all
of the grave+serious bugs as a batch. We would need to snapshot the list at
a point in time and work toward zero so that it doesn't change continuously.
This is the sort of activity which we might repeat periodically to keep
things moving.
> > - 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'd love it if someone could follow up on that. It might start to get
slightly outside the scope of DEX, though, if we get involved in setting up
an ongoing sponsorship/mentoring program. I think that may be a good idea,
but it's less clearly a good DEX project.
For this reason, I feel a bit uncertain about how to organize the new
packages project. It seemed to have traction in Utnubu, so I'm hoping
there's an existing process for how to actually mark these packages "done"
somehow. Finding maintainers and mentors is more of an open-ended process.
> 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.)
The ancient-patches script will keep track of any associated bugs which are
still open.
So far, the "not done" cases include:
- Waiting for response from the maintainer - this should only be temporary,
we shouldn't wait indefinitely or it would defeat our purpose
- Waiting for a new upstream release (problem is fixed upstream) - I
think the bug should be tagged "fixed-upstream" in this case, which we can
track and consider it "done"
- Waiting for comment from upstream (the maintainer doesn't want to include
a patch which is not blessed by upstream) - I'm not sure yet how to handle
this case. What do folks think? We shouldn't block forever on this if we
can avoid it.
--
- mdz
Reply to: